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(54) PC-based open metering system and method 



(57) A transaction evidencing system includes a 
personal computer (PC) comprising a processor, mem- 
ory and hard drive, with a plurality of non-metering 
application programs that selectively run on the PC. An 
unsecured printer is operatively coupled to the PC for 
printing in accordance with the non-metering applica- 
tion programs. A portable vault card that is removably 
coupled to the PC is programmed to generate tokens 
generation and perform transaction accounting. An 
application interface module in the PC, which interfaces 
with the non-metering application programs, issues a 
request for one digital tokens in response to requests for 
indicia from a non-metering application program. A 
secure communications module in the PC, which 
securely communicates with the vault card when the 
vault card is coupled to the PC, sends the request for 
digital token to the vault card and receives a digital 
token generated by the vault card. An indicia bitmap 
generation module generates an indicia bitmap in the 
PC from the digital token and stores it in memory. The 
indicia bitmap is accessed by the non-metering applica- 
tion program when a print indicia operation is selected. 
A transaction capture module in the PC stores on the 
hard drive a transaction record corresponding to each 
issued digital token and associated postal data. The 
application interface module, the secure communica- 
tions module, the indicia bitmap generation module and 
the transaction capture module are part of a dynamic 



link library module in the PC. 
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Description 

Reld of the Invention 



The present invention relates generally to value 
printing systems and, more particularly, to value printing 
systems wherein a printer is not dedicated to a metering 
module. 

Related Ap plication*? 

The present application is related to the following 
U.S. Patent Applications Serial Nos. [Attorney Dockers 
E-416, E-415. E-417, E-418, E-420, E-419, E-444, E- 
452, E-463 and E-466], each filed concurrently here- 
with, and assigned to the assignee of the present inven- 
tion. 

Background of the Invention 

Since the issuance of U.S. Patent No. 1,530,852 to 
Arthur H. Pitney, the postage meter has evolved from 
completely mechanics postage meters to meters that 
incorporate extensive use of electronic components. 
Although postage meters have performed satisfactorily 
in the past, and continue to perform satisfactorily, with 
the advancement in computer controlled digital printing 
technology, the United States Postal Service (USPS) 
and other Posts arc considering requirements for new 
technology metering devices. 

The USPS is presently considering requirements 
for two metering device types: dosed systems and open 
systems. In a closed system, the system functionality is 
solely dedicated to metering activity. Examples of dosed 
system metering devices, also referred to as postage 
evidencing devices (PEDs), include conventional digital 
and analog postage meters wherein a dedicated printer 
is securely coupled to a metering or accounting func- 
tion. In a closed system, since the printer is securely 
coupled and dedicated to the meter, printing cannot 
take place without accounting. Recently, Pitney Bowes 
Inc. has introduced the Post Perfect™ meter which is a 
new closed system metering device that includes a ded- 
icated digital printer securely coupled to a secure 
accounting module. 

In an open system, the printer is not dedicated to 
the metering activity, freeing system functionality for 
multiple and diverse uses in addition to the metering 
activity. Examples of open system metering devices 
include personal computer (PC) based devices with sin- 
gle/multi-tasking operating systems, multi-user applica- 
tions and digital printers. An open system metering 
device is a PED with a non-dedicated printer that is not 
securely coupled to a secure accounting module. 

When a PED prints postage indicia on a mailpiece, 
the accounting register within the PED must always 
reflect that the printing has occurred. Postal authorities 
generally require the accounting information to be 
stored within the postage meter in a secure manner with 
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security features that prevent unauthorized and unac- 
counted for postage printing or changes in the amounts 
of postal funds stored in the meter. In a closed system, 
the meter and printer are integral units, i.e., interlocked 
5 in such a manner as to ensure that the printing of a 
postage indicia cannot occur without accounting. 

Since an open system PED utilizes a printer that is 
not used exclusively for printing proof of postage pay- 
ment, additional security measures are required to pre- 
10 vent unauthorized printing evidence of postage 
payment. Such security measures include crypto- 
graphic evidencing of postage payment by PEDs in the 
open and closed metering systems. The postage value 
for a mail piece may be encrypted together with other 
75 data to generate a digital token. A digital token is 
encrypted information that authenticates the informa- 
tion imprinted on a mail piece including postage values. 

Examples of systems for generating and using dig- 
ital tokens are described in U.S. Patents Nos. 
20 4,757,537, 4,831,555, 4,775,246, 4,873,645, and 
4,725.718. the entire disclosures of which are hereby 
incorporated by reference. These systems employ an 
encryption algorithm to encrypt selected information to 
generate at least one digital token for each mailpiece. 
25 The encryption of the information provides security to 
prevent altering of the printed information in a manner 
such that any misuse of the tokens is detectable by 
appropriate verification procedures. 

Typical information which may be encrypted as part 
30 of a digital token includes origination postal code, ven- 
dor identification, data identifying the PED, piece count, 
postage amount, date, and, for an open system, desti- 
nation postal code. These items of information, collec- 
tively referred to as postal data, when encrypted with a 
35 secret key and printed on a mail piece provide a very 
high level of security which enables the detection of any 
attempted modification of a postal revenue block or a 
destination postal code. A postal revenue block is an 
image printed on a mail piece that includes the digital 
40 token used to provide evidence of postage payment. 
The Postal data may be printed both in encrypted and 
unencrypted form in the postal revenue block, postal 
data serves as an input to a Digital Token Transforma- 
tion which is a cryptographic transformation computa- 
45 tion that utilizes secret key to produce digital tokens. 
Results of the Digital Token Transformation, i.e., digital 
tokens, are available only after completion of the 
Accounting Process As used herein "digital token" may 
be an encryption of all postal data or a subset thereof. 
so Digital tokens are utilized in both open and closed 
metering systems. However, for open metering sys- 
tems, the non-dedicated printer may be used to print 
other information in addition to the postal revenue block 
and may be used in activity other than postage evidenc- 
55 ing. In an open system PED, addressee information is 
included in the postal data which is used in the genera- 
tion of the digital tokens. Such use of the addressee 
information creates a secure link between the mailpiece 
and the postal revenue block and allows unambiguous 
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authentication of the mail piece. 

Preferably, two digital tokens are used to authenti- 
cate postal data and postage payment. The first is pro- 
duced by a Digital Token Transformation using a secret 
key held by the Postal Service and the mailer's PED. s 
The second is produced by a Digital Token Transforma- 
tion using a secret key held by the PED vendor and the 
mailer's PED. The fact that two independent entities 
hold separate verification secrets greatly enhances the 
security of the system because it provides the Postal 10 
Service and the vendor with independent means to 
authenticate the postal revenue block, and thus, verify 
postage payment The use of the second Digital Token 
Transformation using the vendor's secret key is an 
optional part of the security which authenticates post- is 
age payment by a particular vendor's device. The use of 
two digital tokens (postal and vendor) is described in US 
Patent No. 5.390,251 and pending U.S. Patent Applica- 
tion Serial No. 08/242,564, filed May 13, 1994, both 
assigned to the assignee of the present invention, the 20 
entire disclosures of which are hereby incorporated by 
reference. 

Summary of the Invention 

25 

In accordance with the present invention some of 
the functionality typically performed in the vault of a con- 
ventional postage meter has been removed from the 
vault of a PC-based open metering system and is per- 
formed in the PC. It has been discovered that this trans- 30 
fer of functionality from the vaidt to the PC does not 
effect the security of the meter because the security of 
the PC-based open metering system is in the informa- 
tion being processed not in the meter itself. 

Thus,_the present invention provides a PC-based 35 
open metering system that comprises a PC , special 
Windows-based software, a printer and a plug-in 
peripheral as a vault to store postage funds. The PC 
meter uses a personal computer and its non-secure and 
non-dedicated printer to print postage on envelopes and 40 
labels at the same time it prints a recipient address. 

The present invention provides a PC based open 
meter system, which consists of a personal computer 
(PC), a digital printer, a removable electronic vault, an 
optional modem for funds recharge (debit or credit), a 45 
PC software module in the form of a Dynamic Link 
Library (DLL) and a user interface module. The vault is 
a secure encryption device for digital token generation, 
funds management and traditional accounting func- 
tions. The DLL module performs all communications so 
with the vault, and provides an open interface to Win- 
dows-based applications. Secure communication 
between the DLL and the vault is desired but is not nec- 
essary for system security. The DLL module obtains 
from the vault transaction records comprising digital ss 
tokens issued by the vault and associated postal data 
and generates an electronic indicia image. The usage of 
postal funds and the transaction record are stored in the 
vault. Another copy of the usage of postal funds and the 



transaction record may be stored on the PC's hard drive 
as backup. The user interface module obtains the elec- 
tronic indicia image from the DLL module for printing the 
postal revenue block on a document, such as an enve- 
lope. The user interface also communicates with the 
vault via the DLL for remote refills and for performing 
administrative functions. 

The present invention provides open system meter- 
ing that includes security to prevent tampering and false 
evidence of postage payment as well as the ability to do 
batch processing of envelopes, review of indicia and 
addressing on envelope before printing. 

In accordance with the present invention a transac- 
tion evidencing system includes a personal computer 
(PC) comprising a conventional processor, memory and 
hard drive, with a plurality of non-metering application 
programs that selectively run on the PC. An unsecured 
printer is operatively coupled to the PC for printing in 
accordance with the non-metering application pro- 
grams. A portable vault card that is removably coupled 
to the PC is programmed to generate tokens and per- 
form transaction accounting. An application interface 
module in the PC, which interfaces with the non-meter- 
ing application programs, issues a request for digital 
tokens in response to requests for indicia from a non- 
metering application program. A secure communica- 
tions module in the PC. which securely communicates 
with the vault card when the vault card is coupled to the 
PC, sends the request for digital token to the vault card 
and receives a digital token generated by the vault card. 
An indicia bitmap generation module generates an indi- 
cia bitmap in the PC from the digital token and stores it 
in memory. The indicia bitmap is accessed by the non- 
metering application program when a print indicia oper- 
ation is selected. A transaction capture module in the 
PC stores on the hard drive a transaction record corre- 
sponding to each issued digital token and associated 
postal data. The application interface module, the 
secure communications module, the indicia bitmap gen- 
eration module and the transaction capture module are 
part of a dynamic link library module in the PC. 

Description of the Drawings 

The above and other objects and advantages of the 
present invention will be apparent upon consideration of 
the following detailed description, taken in conjunction 
with accompanying drawings, in which like reference 
characters refer to like parts throughout, and in which: 

Fig. 1 is a block diagram of a PC-based metering 
system in accordance with the present invention; 
Fig. 2 is a schematic block diagram of the PC- 
based metering system of Fig. 1 including a remov- 
able vault card and a DLL in the PC; 
Fig. 3 is a schematic block diagram of the DLL in 
the PC-based metering system of Fig. 1 including 
interaction with the vault to generate indicia bitmap; 
Fig. 4 is a block diagram of the DLL sub-modules in 
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the PC-based metering system of Fig. 1 ; 

Fig. 5 is a flow diagram of vault mode transitions in 

the PC-based metering system of Rg. 1 ; r 

Fig. 6 is a flow disgram of power state transitions of 

the vault card in the PC-based metering system of s 

Fig. 1; 

Fig. 7 is a flow chart of the Secure Communications 
sub-module in the PC-based metering system of 
Fig. 1; 

Fig. 8 is a flow chart of the Transaction Capture 10 
sub-module in the PC-based metering system of 
Fig. 1; 

Fig. 9 is an representation of indicia printed by the 
PC-based metering system of Fig. 1 ; 
Fig. 10 is a flow chart of the Secure Indicia Image is 
Storage sub-module in the PC-based metering sys- 
tem of Fig. 1 ; 

Fig. 1 1 is a diagrammatic representation of a docu- 
ment printed by the PC-based metering system of 
Rg. 1 with indicia printed thereon; and 20 
Fig. 12 is a diagrammatic representation of a three 
windowed envelope in which the document of Fig. 
1 1 is inserted with the indicia showing through one 
of the windows. 

Fig. 13 is a block diagram of a PC-Network meter- 25 
ing system in accordance with the present inven- 
tion: 

Fig. 14 is a schematic block diagram of the PC-Net- 
work metering system of Fig. 13 including a remov- 
able vault card in a server PC and a DLL in each of 30 
the PC's; 

Rg. 15 is a schematic block diagram of the client 
and server PC's in the PC-Network metering sys- 
tem of Rg. 13 including interaction with the vault to 
generate indicia bitmap; 35 

Detailed Description of the Present Invention 

In describing the present invention, reference is 
made to the drawings, wherein there is seen in Figs. 1 40 
and 2 an open system PC-based postage meter, also 
referred to herein as a PC meter system, generally 
referred to as 10. comprising a conventional personal 
computer configured to operate as a host to a remova- 
ble metering device or electronic vault, generally 45 
referred to as 20. in which postage funds are stored. PC 
meter system 10 uses the personal computer and its 
printer to print postage on envelopes at the same time it 
prints a recipient's address or to print labels for pre- 
addressed return envelopes or large mailpieces. It will so 
be understood that although the preferred embodiment 
of the present invention is described as a postage 
metering system, the present invention is applicable to 
any value metering system that includes transaction evi- 
dencing. 55 

As used herein, the term personal computer is used 
generically and refers to present and future micro- 
processing systems with at least one processor opera- 
tive^ coupled to user interface means, such as a 



display and keyboard, and storage media. The personal 
computer may be a workstation that is accessible by 
more than one user. 

The PC-based postage meter 10 includes a per- 
sonal computer (PC) 12, a display 14, a keyboard 16, 
and an unsecured digital printer 18, preferably a laser or 
ink-jet printer. PC 12 includes a conventional processor 
22, such as the 80486 and Pentium processors manu- 
factured by Intel, and conventional hard drive 24, floppy 
drive(s) 26, and memory 28. Electronic vault 20, which 
is housed in a removable card, such as PCMCIA card, 
is a secure encryption device for postage funds man- 
agement, digital token generation and traditional 
accounting functions. PC meter system 10 may also 
include an optional modem 29 which is located prefera- 
bly in PC 12. Modem 29 may be used for communicat- 
ing with a Postal Service or a postal authenticating 
vendor for recharging funds (debit or credit). A descrip- 
tion of such communication by modem is described in 
U.S. Patent No. 4,831 ,555, incorporated herein by refer- 
ence. In an alternate embodiment the modem may be 
located in PCMCIA card. 

PC meter system 10 further includes a Windows- 
based PC software module 34 (Figs. 3 and 4) that is 
accessible from conventional Windows-based word 
processing, database and spreadsheet application pro- 
grams 36. PC software module 34 includes a vault 
dynamic link library (DLL) 40, a user interface module 
42, (Fig. 2) and a plurality of sub-modules that control 
the metering functions. The DLL is an application pro- 
gramming interface (API) that is used by in Windows- 
based programs. It will be understood that the present 
invention is suitable for use with an API corresponding 
to other than Windows-based programs. 

DLL module 40 securely communicates with vault 
20 and provides an open interface to Microsoft Win- 
dows-based application programs 36 through user 
interface module 42. DLL module 40 also securely 
stores an indicia image and a copy of the usage of 
postal funds of the vault. User interface module 42 pro- 
vides application programs 36 access to an electronic 
indicia image from DLL module 40 for printing the postal 
revenue block on a document, such as an envelope or 
label. User interface module 42 also provides applica- 
tion programs the capability to initiate remote refills and 
to perform administrative functions. 

Thus, PC-based meter system 10 operates as a 
conventional personal computer with attached printer 
that becomes a postage meter upon user request. 
Printer 1 8 prints all document normally printed by a per- 
sonal computer, including printing letters and address- 
ing envelopes, and in accordance with the present 
invention, prints postage indicia. 

A description of the key components of PC-based 
meter system 10 are described below followed by a 
description of the preferred operation of PC-based 
meter system 1 0. A description of the digital token gen- 
eration process is disclosed in co-pending U.S. Patent 
Applications Serial Nos. [Attorney Dockets E-416, E- 
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415 and E-419], which are incorporated herein in their 
entirety by reference. 

The Vault 

In the preferred embodiment of the present inven- 
tion, the vault is housed in a PCMCIA I/O device, or 
card, which is accessed through a PCMCIA controller 
32 in PC 1 2. A PCMCIA card is a credit card size periph- 
eral or adapter that conforms to the standard specifica- 
tion of the Personal Computer Memory Card 
International Association. 

Referring now to Figs. 2 and 3, the PCMCIA card 
includes a microprocessor 44, non-volatile memory 
(NVM) 46, clock 48, an encryption module 50 and an 
accounting module 52. The encryption module 50 may 
implement the NBS Data Encryption Standard (DES) or 
another suitable encryption scheme. In the preferred 
embodiment, encryption module 50 is a software mod- 
ule. It will be understood that encryption module 50 
could also be a separate device, such as a separate 
chip connected to microprocessor 44. Accounting mod- 
ule 52 may be EEPROM that incorporates ascending 
and descending registers as well as postal data, such 
as origination ZIP Code, vendor identification, data 
identifying the PC-based postage meter 10, sequential 
piece count of the postal revenue block generated by 
the PC-based postage meter 10, postage amount and 
the date of submission to the Postal Service. As is 
known, an ascending register in a metering unit records 
the amount of postage that has been dispensed, i.e., 
issued by the vault, in all transactions and the descend- 
ing register records the value, i.e., amount of postage, 
remaining in the metering unit, which value decreases 
as postage is issued. 

The hardware design of the vault includes an inter- 
face 56 that communicates with the host processor 22 
through PCMCIA controller 32. Preferably, for added 
physical security, the components of vault 20 that per- 
form the encryption and store the encryption keys 
(microprocessor 44, ROM 47 and NVM 46) are pack- 
aged in the same integrated circuit device/chip that is 
manufactured to be tamper proof. Such packaging 
ensures that the contents of NVM 46 may be read only 
by the encryption processor and are not accessible out- 
side of the integrated circuit device. Alternatively, the 
entire card could be manufactured to be tamper proof. 

In accordance with the present invention, the open 
system vault 20 is strictly a slave device to PC 12. Host 
processor 22 generates a command and vault 20 
replies with a response. The vault 20 does not generate 
unsolicited messages. Thus, PC 12 requests vault sta- 
tus whenever my transaction is initiated. 

Referring now to Fig. 5. vault 20 has four security 
access levels: normal mode 60, service mode 62, privi- 
leged mode 64 and manufacturing mode 66. In normal 
mode 60, commands available to users are processed. 
In service mode 62, normal mode commands and serv- 
ice related commands arc processed. In privilege mode 



64, all commands except direct access to NVM are 
processed. In manufacturing mode 66, all commands 
are processed. An access level is assigned to every 
command that is processed by the vault. Passwords are 

5 assigned to the various access levels. For example, to 
enter service mode 62 from the normal mode 60, a 
service password is required. Another password is 
required to enter privileged mode 64. Thus, two pass- 
words, service and privileged, must be entered to 

w access privileged mode 64. Privileged mode 64 cannot 
be accessed from normal mode 60 or manufacturing 
mode 66. 

When a 'blank* vault is manufactured, a manufactur- 
ing vendor puts vault 20 in manufacturing mode 66 to 

is program the NVM 46 of PCMCIA card. NVM 46 is pro- 
grammed with encryption, accounting, funds manage- 
ment and other vault software modules. Then the 
vendor locks a serial number in NVM 46, prohibiting any 
unauthorized access to NVM 46, before delivering 

20 PCMCIA card to a user. The vendor programs vault 20 
to default to normal mode 60 whenever power is 
applied. A manufacturing mode password is required, 
i.e. vault 20 must be in manufacturing mode, to unlock 
the serial number in vault 20. 

25 

Commands From The PC To Control The Vault Power 

PCMCIA card does not include a self contained 
power source. Power to PCMCIA card is controlled by 

30 PC 12 in a conventional manner. When a user inserts 
vault 20 into PCMCIA controller 32 of PC 12, PC 12 
software is in full control of electric power to vault 20. 
Microprocessor 44 in PCMCIA card is always in one of 
the four states: power removed 70, execution 72, idle 

35 74, or power-down 76. Microprocessor 44 enters the 
execution state 72 each time it performs a task specified 
in a command from PC 12. Microprocessor 44 enters 
the idle state 74 after performing such task. Microproc- 
essor 44 enters the power-down 76 if the system 

40 remains idle longer than the user specified idle time. To 
exit power-down state 76, an external signal from PC 12 
wakes up microprocessor 44. Microprocessor 44 is in 
the power removed state 70 whenever PCMCIA card is 
removed from PCMCIA controlled 32 or whenever 

45 PCMCIA controller 32 disables power to PCMCIA card. 
Figure 6 shows the state transitions for power controls. 

Status messages communicate the status of vault 
20 to PC 12. The status messages also serve as 
acknowledgment or failure to acknowledge a given com- 

so mandbyPC12. 

Dynamic Link Library Control of the Vault 

In accordance with the present invention, the func- 
55 tionality of DLL 40 is a key component of PC-base 
meter 10. DLL 40 includes both executable code and 
data storage area 41 that is resident in hard drive 24 of 
PC 12. In a Windows environment, a vast majority of 
applications programs 36, such as word processing and 
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spreadsheet programs, communicate with one another 
using one or more dynamic link libraries. The present 
invention encapsulates all the processes involved in 
metering, and provides an open interface to vault 20 
from all Windows-based applications capable of using a 5 
dynamic link library. In accordance with the present 
invention, any application program 36 can communicate 
with vault microprocessor 44 in PCMCIA card through 
DLL 40. 

In accordance with the present invention, DLL 40 io 
includes the following software sub-modules: secure 
communications 80, transaction capture 82, secure 
indicia image creation and storage 84, and application 
interface module 86. 

15 

Secure Communications 

Since vault 20 is not physically secured to PC 12, it 
would be possible for a user to replace one vault 20 
attached to PC 12 with another vault 20 while a vault 20 
transaction is in process. The Secure Communications 
sub-module 80 prevents this from happening by main- 
taining secure communication between DLL 40 and 
vault 20. Referring now to Fig. 7, the Secure Communi- 
cations sub-module 80 identifies a specific vault 20 25 
when it opens a communication session through PCM- 
CIA controller 32, and maintains communication data 
integrity with the specific vault during the entire commu- 
nication session. When a communication session is ini- 
tiated DLL 40 and vault 20 negotiate a session key at 30 
step 100. All the messages thereafter are 
encoded/decoded using the session key which is used 
for only the one particular communication session. 
Whenever the session key changes during the commu- 
nication session, the communication session termi- 35 
nates and an error message is sent to the user at step 
106. The use of session keys is described in Applied 
Cryptography by Bruce Schneier, published by John 
Wiley and Sons, Inc., 1994. Thus, the session key not 
only provides secure encrypted communication 40 
between DLL 40 and vault 20, but also prevents another 
vault (PCMCIA card) from replacing the vault 20 that 
began a communication session, because the other 
vault does not have the session key negotiated at the 
beginning of the communication session. Secure Com- 45 
munications sub-module 80 also controls secure com- 
munications with the postal data center, for example, 
during refills of the accounting registers in vault 20. 

Transaction Captures 50 

Conventional postage meters store transactions in 
the meter. In accordance with the present invention, 
Transaction Capture sub-module 82 captures each 
transaction record received from vault 20 and records 55 
the transaction record in DLL 40 and in DLL storage 
area 41 on hard drive 24. If there is ample room on hard 
drive 24, such transaction captures can be stored for a 
plurality of different vaults. Referring now to Fig; 8, from 



the moment that a communication session is estab- 
lished, Transaction Capture sub-module 82 monitors 
message traffic at step 120, selectively captures each 
transaction record for token generations and refills, and 
stores such transaction records in DLL 40 at step 124 
and in an invisible and wrrte-protected file 83 in DLL 
storage area 41 at step 126. The information stored for 
each transaction record includes, for example, vault 
serial number, date, piece count, postage, postal funds 
available (descending register), tokens, destination 
postal code and the block check character. A predeter- 
mined number of the most recent records initiated by 
PC 12 arc stored in file 83 which is an induced historical 
file. In the preferred embodiment, file 83 is indexed 
according to piece count but may be searched accord- 
ing to addressee information. File 83 represents the mir- 
ror image of vault 20 at the time of the transaction 
except for the encryption keys and configuration param- 
eters. Storing transaction records on hard drive 24 pro- 
vides backup capability which is described below. 

Indicia Image Creation and Storage 

In a dosed metering system, such as conventional 
postage meters, the indicia is secure because the indi- 
cia printer is dedicated to the meter activity and is phys- 
ically secured to the accounting portion of the meter, 
typically in a tamper-proof manner. In an open metering 
system, such as the present invention, such physical 
security is not present. 

In accordance with the present invention, the entire 
feed graphics image 90 of the indicia 92, shown in Fig. 
9 is stored as compressed data 94 in DLL storage area 
41. Postal data information, including piece count 93a, 
vendor ID 93b, postage amount 93c, serial number 93d, 
date 93e and origination ZIP 93f and tokens 93g are 
combined with the fixed graphics image 90 by Indicia 
Image Creation Module 84. 

Referring now to Fig. 10. when a request for indicia 
is made from an application program in PC 12 at step 
142, Indicia Image Creation Module 84 checks for a dig- 
ital token from vault 20 at step 1 44, and at step 1 46 gen- 
erates a bit-mapped indicia image 96 by expanding the 
compressed fixed graphics image data 94 at step 148 
and combining at step 150 the indicia's feed graphics 
image 90 with some or all of the postal data information 
and tokens received from vault 20. At step 152, the indi- 
cia image is stored in DLL 40 for printing. Sub-module 
84 sends to the requesting application program 36 in 
PC 12 the created bit-mapped indicia image 96 that is 
ready for printing, and then stores a transaction record 
comprising the digital tokens and associated postal data 
in DLL storage area 41 . 

Thus, the bit-mapped indicia image 96 is stored in 
DLL 40 which can only be accessed by executable code 
in DLL 40. Furthermore, only the executable code of 
DLL 40 can access the fixed graphics image 90 of the 
indicia to generate bit-mapped indicia image 96. This 
prevents accidental modification of the indicia because 
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it would be very difficult for a normal user to access, 
intentionally or otherwise, the feed graphics image 90 of 
the indicia and the bit-mapped indicia image 96. 

Application Interface 

The Application Interface sub-module 86 provides 
the following services when requested by an application 
program 36 in PC 12. Application program 36 accepts 
user data through user interface module 42 and prints 
indicia on an envelope or on a label. In the preferred 
embodiment of the present invention, such application 
program 36 would be an off-the-shelf software module, 
such as a word processor or spreadsheet that can 
access DLL 40. In an alternate embodiment application 
program 36 could be a software module dedicated 
solely to accept user data and print indicia on an enve- 
lope or on a label. Application Interface sub-module 86 
provides the destination ZIP data and associated postal 
data needed to create the indicia. Application Interlace 
sub-module 86 requests available postage from vault 20 
and reports the available postage to the requesting 
application program 36. 

When vault 20 is refilled with postage funds from 
the data center. Application Interface sub-module 86 
requests from vault 20 the access code required for 
refills and reports the access code received to the 
Secure Communications sub-module 80 which initiates 
communications with the data center. Application Inter- 
face sub-module 86 initiates the refill and provides the 
amount and combination to vault 20. DLL 40 reports the 
result to the requesting application program 36 which 
acknowledges the refill to the user. 

Application Interface sub-module 86 processes a 
request for indicia received from application program 36 
and forwards the request to Indicia Image Creation and 
Storage sub-module 84. Application Interface sub-mod- 
ule 86 provides postal data, including date, postage, 
and a destination postal code, such as an 11 digit ZIP 
code, to Indicia Image Creation and Storage sub-mod- 
ule 84 which then generates a bit-mapped indicia image 
96. Application Interface sub-module 86 reports to 
application program 36 that the bit-mapped indicia 
image 96 is ready for printing. 

Backup On Hard Drive 

Vault 20 must be a secure device because it con- 
tains the accounting information of the amount of post- 
age remaining in the vault and the postage printed. 
However, the very nature of the security makes it hard to 
recover postal funds in the event a malfunction occurs 
and the vault cannot be accessed by normal operation. 
The present invention enhances the reliability of a PC 
meter system by using the hard disk of the user PC to 
backup the accounting information of the vault. As pre- 
viously described, the transaction capture sub-module 
82 stores transaction files as backup files on hard drive 
24. This provides a benefit that certain functions, such 



as account reconciliation, can be performed even when 
vault 20 malfunctions. Such backup is unavailable in 
conventional postage meters. 

For further security, the backup transaction files can 

5 be encrypted before being stored on hard drive 24 to 
prevent tampering. The number of transactions that are 
maintained on hard drive 24 is limited only by the avail- 
able storage space on hard drive 24. Preferably, at least 
all transactions since the last refill would be maintained 

io as backup. 

A detailed description of recovery from vault mal- 
function is disclosed in co-pending U.S. Patent Applica- 
tion Serial No. [Attorney Docket E-420], which is 
incorporated herein in its entirety by reference. 

15 

Operation of the PC Meter 

Generally, the first action by a user after powering 
up a conventional meter is setting the time and date of 

20 the meter. Setting the date is necessary to generate 
derived keys which are used to generate the digital 
tokens. (Some recent meters have a real time clock 
internal to the meter in which case the time and date 
need only be set once.) The present invention spares 

25 the user from having to set the vault date. 

As previously described, vault 20 does not have an 
independent power source and therefore cannot have a 
continuous running real-time clock. The date must be 
set every time the vault is powered-up. Power is applied 

30 to vault 20 only when it is plugged into PC 12. Thus, the 
date would normally be entered by the user through PC 
12 each time vault 20 is plumed into PCMCIA controller 
32. Since the PC to which the vault is connected has a 
real-time clock, the date setting process may be auto- 

35 mated and made transparent to the user. In accordance 
with the present invention, the time and date set in PC 
12 is sent to vault 20 each time power is initially applied 
to vault 20. The vault date is used by DLL 40 to generate 
the indicia. The vault date may be changed at any time 

40 by the user to facilitate post-dating of mail. 

Upon application of power to vault 20 by PCMCIA 
controller 32, the date of PC 1 2 is obtained through user 
interface 42. The date is then translated into the correct 
format and sent to vault 20 which then sets its date, cal- 

45 culates its date dependent token keys end returns its 
status and the taken keys to PC 12. Additionally, a 
default postage amount (e.g. First Class Postage) may 
be set in a similar manner. This method enables PC 
meter system 10 immediately when vault 20 is plugged 

so into PC 12 without the user having to manually set 
parameters. The user may change the vault date (in 
order to post date mail) or the default postage amount at 
any time. 

In an alternate embodiment, PCMCIA card has its 
55 own internal clock that is automatically set with the time 
and date in PC 12 each time PCMCIA card is inserted 
into PCMCIA controller 32. 

In the preferred operation, a user of an application 
program 36, such as a word processor, highlights a 
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recipient address from a letter or mailing list displayed 
on display 14. The user requests the printing of an enve- 
lope with indicia. A dialog box appears on display 14 
indicating the default postage amount which the user 
may accept or modify. When the postage amount is 
accepted, the entire envelope is previewed with all 
addressing, bar-coding and indicia shown on the enve- 
lope. At this point the user can print the envelope as 
shown or correct any errors that are seen in the preview. 

From the display 14 and keyboard 16, the user can 
change postage amount, date and address information. 
The user can also select and customize a return 
address, slogan, logo and greeting that may be printed 
with the indicia. The present invention also provides 
from the application program 36 the ability for a user to 
check funds available in vault 20 and to initiate 36 the 
automatic refilling of the PC meter through modem 29. 
PC meter system 10 also includes the capability of inter- 
facing with optional software, such as postal rate calcu- 
lation and address hygiene, that improves the 
performance of PC meter system 10. 

PC meter system 10 provides capabilities that are 
not available with conventional postage meters. For 
example, a user can scan in addressee information; 
generate indicia for a batch of envelopes before printing 
any of the envelopes; observe an image of the envelope 
to be printed, including addressee information and indi- 
cia, before printing the envelope; and customize slo- 
gans, logos and greetings to be printed with the indicia 
on the envelope. 

Most personal bills received in the home today 
come with self-addressed, reply envelopes. A user may 
desire to use PC meter system 1 0 to apply open system 
indicia to the self-addressed, reply envelopes. Since the 
open system indicia includes addressee information, 
the user can type such addressee information into PC 
12 before requesting indicia. This task can be simplified 
by using a conventional optical scanner connected to 
PC 12 for scanning in the unique addressee information 
printed on the reply envelope. PC meter system 10 uses 
such unique addressee information to generate tokens 
for the indicia. PC meter system 10 then prints the indi- 
cia to a label printer or label printed on a conventional 
printer, or prints a completely new envelope with the 
scanned address. The label with indicia printed on it, 
could then be applied to the self-addressed, reply enve- 
lope. Using a scanner in this manner eliminates the 
need for a user to manually enter information from the 
self addressed envelope which is a slower method that 
has a higher potential for error. Such error in entering 
addressee information could result in indicia that fails 
open system verification by the Post Office. It will be 
understood that the scanner can also be used for scan- 
ning in addresses from a printed mailing list. Finally, if 
the envelope was prepared previously or at another PC, 
the addressee information can be scanned as 
described above. 

As previously described, in PC meter system 10 the 
printer Is not dedicated to the metering function and the 



Indicia are stored in PC 12 before printing. Thus, indicia 
can be generated individually or for a batch of address- 
ees and then printed at a later time at the user's discre- 
tion. Such delayed printing and batch processing is 
5 described in more detail in co-pending U.S. Patent 
Application Serial No. [Attorney Docket E-452], which is 
incorporated herein in its entirety by reference. 

As with any document prepared in a Window-based 
PC system, a user may observe, through the application 
10 program 36 in which an envelope was created, an 
image of a fully prepared envelope or batch of enve- 
lopes to be printed, including addressee information 
and indicia, before printing any of the envelopes. In 
addition, PC meter system 10 provides a user with the 
is ability to customize return addresses, slogans, logos 
and greetings that are to be printed with the indicia on 
the envelope. 

In an alternate embodiment of PC meter 10, the 
electronic vault is in an IC token, such as manufactured 
20 by CDSM of Phoenix, Arizona, that is inserted into a 
token receptacle of a PCMCIA card and programmed to 
operate as the vault in a similar manner as described for 
PCMCIA card. In another alternate embodiment, the 
electronic vault is in a smart diskette, such as manufac- 
25 tured by SmartDisc Security Corp. of Naples, Florida, 
that is programmed to operate in a similar manner as 
described for PCMCIA card. 

In another alternate embodiment of PC meter 10, 
the electronic vault is a tamper proof, hardware periph- 
30 eral, such as a dongle, that is attached to a serial, par- 
allel or SCSI port of the PC. In yet another alternate 
embodiment, not shown, the vault is internal to PC-12, 
for example a separate chip within PC-12 that functions 
in a manner similar to vault 20. 
35 Finally, the present invention provides an alternate 
method of postage evidencing which eliminates the 
need to print anything on an envelope. PC meter system 
12 can print an open system indicia on a letter itself as 
shown in Fig. n. The format of such a letter 170 
40 includes a return address 172 in the upper left corner, 
an open system indicia 174 in the upper right corner, a 
destination address 176 below the return address, and 
the body of the letter 1 78 below the destination address. 
Using a windowed envelope 1 80 with three windows, as 
45 shown in Fig. 12, the return address is visible through 
an upper left corner window 182, the destination 
address is visible through a lower left window 184, and 
the indicia is visible through an upper right window 186. 
ft will be understood that the present invention can be 
so used to print indicia anywhere on the letter or document 
being printed to accommodate alternately configured 
windowed envelopes, such as a single, large windowed 
envelope. The present invention is also suitable for 
printing indicia on a one piece mailer. The foregoing 
55 method of mailing a letter with indicia printed directly on 
the letter and visible through a window of the envelope 
eliminates a finishing step in production mail relating to 
matching a separately printed envelope with its corre- 
sponding letter. It has been a challenge to insert a letter 
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to the corresponding envelope when the letters and 
envelopes are printed separately. Thus the present 
invention simplifies and eliminates errors in the mail 
preparation process. 

In yet another alternate embodiment of a PC-based s 
metering system, PC 12 is a host computer in a network 
serving a plurality of users in which the vault is active 
within the host computer and requests for indicia origi- 
nate from and printing of indicia occur at a local PC. 

In Figs. 13-15, an open system network-based io 
postage meter, also referred to herein as a network- 
based metering system, generally referred to as 1 , com- 
prising a server 10 and a plurality of clients 11. Server 
10 is configured to operate as a host to a removable 
metering device or electronic vault, generally referred to is 
as 20, in which postage funds are stored. 

In the following description and in the drawings, 
components common to server 10 and clients 11 are 
distinguished, when necessary, by referring to the client 
components with a prime designation. When the com- 20 
ponent functionality is common to both server and client 
PC's the description does not distinguish between 
server and client. 

The server 10 and clients 11 include the following 
common components: personal computer (PC) 12, a 25 
display 14, a keyboard 16. and an unsecured digital 
printer 18, preferably a laser or ink-jet printer. Each PC 
12 includes a conventional processor 22, such as the 
80486 and Pentium processors manufactured by Intel, 
and conventional hard drive 24, floppy drive(s) 26, and 30 
memory 28. Server 10 includes an electronic vault 20, 
which is housed in a removable card, such as PCMCIA 
card. Electronic vault 20 is a secure encryption device 
for postage funds management, digital token generation 
and traditional accounting functions. Server 1 0 may also 35 
include an optional modem 29 which is located in PC 
12, preferably, or in card. Modem 29 may be used for 
communicating with a Postal Service or a postal 
authenticating vendor for recharging funds (debit or 
credit). A description of such communication by modem 40 
is described in U.S. Patent No. 4,831,555, incorporated 
herein by reference. In an alternate embodiment the 
modem may be located in PCMCIA card. 

Each of the PC's 12 includes a Windows-based PC 
software module 34 (Fig. 3) that is accessible from con- 45 
ventional Windows-based word processing, database 
and spreadsheet application programs 36. PC software 
module 34 includes a dynamic fink library (DLL) 40, a 
user interface module 42, and a plurality of sub-mod- 
ules that control the metering functions. In server 10, so 
DLL module 40 securely communicates with vault 20 
and clients 11. In client 11, DLL module 40' securely 
communicates with server 10. DLL 40, in server 10 and 
client 1 1 , provides an open interface to Microsoft Win- 
dows-based application programs 36 through user ss 
interface module 42. DLL module 40 also securely 
stores transaction records reflecting the usage of postal 
funds of vault 20. User interface module 42 provides 
application programs 36 access to an electronic indicia 



image from DLL module 40 for printing the postal reve- 
nue block on a document, such as an envelope or label. 
User interface module 42 also provides application pro- 
grams the capability to initiate remote refills and to per- 
form administrative functions. 

Thus, network-based metering system 1 operates 
as a conventional network, except that a client or net- 
work printer prints postage upon user request. Printers 
18 print alt documents normally printed by a personal 
computer, including printing letters and addressing 
envelopes, and in accordance with the present inven- 
tion, prints postage indicia. Network-based meter sys- 
tem 1 uses server 10 to issue postage and one of the 
printers to print the issued postage on envelopes at the 
same time it prints a recipient's address or to print labels 
for pre-addressed return envelopes or large mailpieces. 
It will be understood that although the preferred embod- 
iment of the present invention is described as a postage 
metering system, the present invention is applicable to 
any value metering system that includes transaction evi- 
dencing. It will also be understood that the present 
invention could also be used in a network in which a net- 
work printer, such as the server printer, is used to print 
envelopes with indicia, when local printers are not avail- 
able to some or all of the client PC's. 

A description of the key components of network- 
based metering system 1 are described below followed 
by a description of the preferred operation of network- 
based metering system 1. 

Dynamic Link Library Control of the Vault and Network 
Communications 

In accordance with the present invention, the func- 
tionality of DLL's 40 and 40' in server and client PC's, 
respectively, is a key component of network-based 
metering 1. DLL 40 includes both executable code and 
data storage area 41 that is resident in hard drive 24 of 
PC 12. In a Windows environment, a vast majority of 
applications programs 36, such as word processing and 
spreadsheet programs, communicate with one another 
using one or more dynamic link libraries. The present 
invention encapsulates all the processes involved in 
metering, and provides an open interface to vault 20 
from all Windows-based applications capable of using a 
dynamic link library. In accordance with the present 
invention, any client application program 36' can com- 
municate with vault microprocessor 44 in PCMCIA card 
through DLL 40' and server PC 12. 

In accordance with the present invention, DLL 40 
includes the following software sub-modules: secure 
communications 80, transaction captures 82, secure 
indicia image creation and storage 84, and application 
interface module 86. 

Secure Communications 

Since vault 20 is not physically secured to server 
PC 12, it may be possible for that one vault 20 attached 
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to server PC 12 is replaced with another vault 20 while 
a vault transaction is in process. The Secure Communi- 
cations sub-module 80 prevents this from happening by 
maintaining secure communication between server DLL 
40 and vault 20. Secure Communications. sub-module 
80 in server 1 1 identifies a specific vault 20 when it 
opens a communication session through PCMCIA con- 
troller 32, and maintains communication data integrity 
with the specific vault during the entire communication 
session. Similarly, when a communication session is ini- 
tiated between client 1 1 and a server 10, Secure Com- 
munications sub-module 80 maintains communication 
data integrity between the client 11 and server 10. 
Referring now to Fig. 5, when a communication session 
is initiated, between server DLL 40 and vault 20, or 
between client 1 1 and server 10, a session key is nego- 
tiated at step 100. All the messages thereafter are 
encoded/decoded using the session key which is used 
for only the one particular communication session. 
Whenever the session key changes during the commu- 
nication session, the communication session termi- 
nates and an error message is sent to the user at step 
106. The use of session keys is described in Applied 
Cryptography by Bruce Schneier. published by John 
Wiley and Sons, Inc., 1994. Thus, the session key not 
only provides secure encrypted communication during 
a token request and issue, but also prevents another 
vault (PCMCIA card) from replacing the vault 20 that 
began a communication session, because the other 
vault does not have the session key negotiated at the 
beginning of the communication session. The secure 
communications between server 10 and client 11 
ensures that only the client requesting a token can 
receive the token. Secure Communications sub-module 
80 in server 1 1 also controls secure communications 
with the postal data center, for example, during refills of 
the accounting registers in vault 20. 

Transaction Captures 

Conventional postage meters store transactions in 
the meter. In accordance with the present invention, 
Transaction Capture sub-module 82 in server 10 cap- 
tures each transaction record received from vault 20 
and records the transaction record in DLL 40 and in DLL 
storage area 41 on hard drive 24. When server 10 
sends the transaction record to client 1 1 , Transaction 
Capture sub-module 82' in client 1 1 captures the trans- 
action record and records the transaction record in DLL 
40' and in DLL storage area 41' on hard drive 24'. Refer- 
ring now to Fig. 6, from the moment that a communica- 
tion session is established, between server DLL 40 and 
vault 20, or between client 1 1 and server 10, respective 
Transaction Capture sub-modules 82 and 82* monitor 
message traffic at step 120, selectively capture each 
transaction record for token generations and refills, and 
store such transaction records in respective DLLs 40 
and 40* at step 124 and in an invisible and write-pro- 
tected files 83 and 83' in DLL storage areas 41 and 4V 
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at step 126. The information stored for each transaction 
record includes, for example, vault serial number, date, 
piece count, postage, postal funds available (descend- 
ing register), tokens, destination postal code and the 

5 block check character. A predetermined number of the 
most recent records initiated can be stored in this man- 
ner by indexing files 83 and 83' accordingly. In the pre- 
ferred embodiment files 83 and 83' are indexed 
according to piece count but may searched according to 

10 addressee information. Server file 83 represents the 
mirror image of vault 20 at the time of the transaction 
except for the encryption keys and configuration param- 
eters. Client file 83' may represent a subset of the image 
of vault 20 at the time of the transaction because each 

is client 1 1 stores transaction records of transactions initi- 
ated by such client. Storing transaction records on hard 
drive 24 provides backup capability which is described 
below. 

A description of a digital token generation process 

20 is disclosed for a PC-meter system in the related U.S. 
Patent Applications Serial Nos. [Attorney Dockets E- 
416, E-415 and E-419], which are incorporated herein 
in their entirety by reference. The digital token genera- 
tion process for network-based metering system 1 is the 

2S same as described in the related applications except 
that a client application program 36* sends a request for 
digital token to vault 20 through client DLL 40* and 
server DLL 40 as shown in Fig. 3. The generated token 
is sent to the client DLL 40' through the server DLL 40 

30 for use in generating an indicia. In the present invention, 
when a request for token is sent from a client to server 
10, all postal information that is needed to calculate the 
token as well as parameters identifying the client, such 
as user ID, password and client PC identification, must 

35 accompany the request since multiple clients may be 
requestig tokens simultaneously. 

Referring now to Fig. 15, a request for indicia is 
made, at step 142, from application program 36* in client 
11 to server 10. At step 144, Secure Communications 

40 sub-module 80' in client 1 1 checks for a response from 
server 10. When a response is received, Indicia Image 
Creation and Storage sub-module 84* checks, at step 
146, the response for postal data, including at least one 
digital token, if the postal data has not been sent with 

45 the response, at step 148, an error condition is proc- 
essed that results in a message to the user. If the 
response from server 10 included the expected postal 
data, at step 150, Indicia Image Creation and Storage 
sub-module 84' generates a bit-mapped indicia image 

so 96 by expanding the compressed fixed graphics image 
data 94, at step 152, and combining, at step 154, the 
indicia's fixed graphics image 90 with some or ail of the 
postal data information and tokens received from vault 
20. At step 1 56, the indicia image is stored in DLL 40' for 

55 printing. Sub-module 84' sends to the requesting appli- 
cation program 36' in client PC 12' the created bit- 
mapped indicia image 96 that is ready for printing, and 
then stores a transaction record comprising the digital 
tokens and associated postal data in DLL storage area 



10 




19 EP0 780 

41 \ 

Thus, the bit-mapped indicia image 96 is stored in 
DLL 40' which can only be' accessed by executable 
code in DLL 40'. Furthermore, only the executable code 
of DLL 40* can access the fixed graphics image 90 of s 
the indicia to generate bit-mapped indicia image 96. 
This prevents accidental modification of the indicia 
because it would be very difficult for a normal user to 
access, intentionally or otherwise, the fixed graphics 
image 90 of the indicia and the bit-mapped indicia 10 
image 96. 

When the request for indicia is made, from applica- 
tion program 36', Secure Communications sub-module 
80 in server 10 checks for the request from client 1 1 , at 
step 160. When the request is received, Secure Com- 15 
munications sub-module 80 requests tokens from vault 
20, at step 162. At step 164, Secure Communications 
sub-module 80 checks for a transaction record, includ- 
ing digital token, from vault 20. If a transaction record is 
not received in response to the request from server 10, so 
an error is processed, at step 166, resulting in an error 
message to client 11. If a transaction record is received, 
then, at step 168, the transaction record is stored in DLL 
40 and DLL storage area 41. At step 170, Secure Com- 
munications sub-module 80 sends the postal data 25 
received as in the transaction record, including token 
and piece count, to client 1 1 . 

The request for indicia most likely will originate from 
a client 11 but could originate from server 10.. When 
server 1 0 originates a request for indicia server 1 0 f unc- 30 
tions as a PC-based meter. 

Application Interface 

This Application Interface sub-module operates as 35 
previously described for the basic PC meter. 

As previously described, the transaction capture 
sub-modules 82 and 82' store transaction files as 
backup files on hard drives 24 and 24'. This provides a 
benefit that certain functions, such as account reconcil- 40 
iation, can be performed even when vault 20 malfunc- 
tions. Such backup is unavailable in conventional 
postage meters. 

For further security, the backup transaction files can 
be encrypted before being stored on hard drives 24 and 45 
24' to prevent tampering. The number of transactions 
that are maintained on hard drives 24 and 24' is limited 
only by the available storage space on the hard drives. 
Preferably, at least all transactions since the last refill 
could be maintained on server 10 as backup. so 

In the preferred operation, a user of an application 
program 36 (running in either client 11 or server 10). 
such as a word processor, highlights a recipient address 
from a letter or mailing list displayed on display 14. The 
user requests the printing of an envelope with indicia. A 55 
dialog box appears on display 14 indicating the default 
postage amount which the user may accept or modify. 
When the postage amount accepted, the entire enve- 
lope is previewed with all addressing, bar-coding and 
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indicia shown on the envelope. At this point the user can 
print the envelope as shown or correct any errors that 
are seen in the preview. 

As previously described, in network-based meter- 
ing system 1 the printers are not dedicated to the meter- 
ing function and the indicia are stored in PC 12 before 
printing. Thus, tokens can be generated individually or 
for a batch of addressees stored in the requesting client 
1 1 which can later generate an indicia from each of the 
tokens and then print the indicia at the user's discretion. 

While the present invention has been disclosed and 
described with reference to a single embodiment 
thereof, it will be apparent, as noted above that varia- 
tions and modifications may be made therein, (t is, thus, 
intended in the following claims to cover each variation 
and modification that falls within the true spirit and 
scope of the present invention. 

In the foregoing, the following attorney docket refer- 
ences indicate the US-applications shown in the follow- 
ing table. All these applications have corresponding 
European Applications and are hereby incorporated 
herein by reference: 

E-415 Serial No. 08/575,106 

E-416 serial No. 08/575.107 

E-41 7 Serial No. 08/574,746 

E-418 Serial No. 08/574,745 

E-419 Serial No. 08/575.110 

E-420 Serial No. 08/574,743 

E-421 Serial No. 08/575,1 1 2 

E-444 Serial No. 08/575,109 

E-452 Serial No. 08/575,104 

E-463 Serial No. 08/574,749 

E-466 Serial No. 08/575, 111 

E-462 Serial No. 08/588,499 

Claims 

1. A transaction evidencing system, comprising 

a personal computer (PC), an unsecured 
printer and portable vault mess removable cou- 
pled to said PC, and user interface means, said 
PC including a processor, memory and storage 
means, said storage means including at least 
one non-metering application program that is 
selectively run on said PC, said unsecured 
printer connected to said PC for printing in 
accordance with said non-metering application 
program, said portable vault means including 
digital token generation means and transaction 
accounting means, the system comprising: 
vault interface means in said PC for effecting 
communications between said portable vault 
means and said non-metering application pro- 
gram and for performing metering functions 
other than metering functions performed in 
said portable vault means, said vault interface 
means comprising: 
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an application interface module for inter- 
facing with said non-metering application 
program; 

a communications module for communi- 
cating with said portable vault means; 
an indicia image creation and storage 
module for generating indicia bitmaps and 
storing said indicia bitmaps in said storage 
means; and 

a transaction capture module for storing in 
said storage means transaction records 
generated in said portable vault means. 

The transaction evidencing system of claim 1 
wherein said portable vault means comprises a 
vault card that is removably coupled to said PC, 
said PC including means for removably coupling 
said vault card to said PC. 

The transaction evidencing system of claim 2, 
wherein said vault card is a PCMCIA card. 

The transaction evidencing system of claim 1. fur- 
ther comprising: 

means in said PC for capturing in said storage 
means a transaction record corresponding to 
said digital token, said transaction record 
including said digital token and said predeter- 
mined information. 

The transaction evidencing system of claim 4, 
wherein said vault interface means are part of a 
dynamic link library module in said PC. 

The transaction evidencing system of claim 4, 
wherein a batch of digital tokens may be generated 
before any indicia bitmaps corresponding to said 
batch of digital tokens are generated. 

The transaction evidencing system of claim 4, 
wherein said transaction record is encrypted before 
being captured in said storage means. 

The transaction evidencing system of claim 4, 
wherein a plurality of consecutive ones of said 
transaction records are stored in said storage 
means as backup to information stored in said port- 
able vault means. 

The transaction evidencing system of claim 1, 
wherein said storage means is a hard drive of said 
PC. 

The transaction evidencing system of claim 1, 
wherein said portable vault means is programmed 
with a plurality of security access levels including at 
least a default mode for normal user access and at 
least one restricted mode that is accessed by pass- 
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word. 

11. The transaction evidencing system of claim 1, fur- 
ther comprising means coupled to said PC for scan- 
ning addressee information for selection by said 
non -metering application programs when request- 
ing indicia. 

12. The transaction evidencing system of claim 1, 
wherein said vault interface means provides said 
indicia bitmap to said non-metering application pro- 
gram for viewing an image of said indicia bitmap on 
a display coupled to said PC before printing said 
indicia bitmap. 

13. The transaction evidencing system of claim 1 
wherein said indicia image creation and storage 
module generates a postage indicia bitmap. 



20 14. 



The transaction evidencing system of claim 1, 
wherein said indicia bitmap generating means gen- 
erates said indicia bitmap by combining indicia 
graphics stored in said storage means with said 
digital token and said predetermined information. 



15. The transaction evidencing system of claim 1 
wherein said application interface module issues a 
request for at least one digital token in response to 
a request for incOca from said non-metering applica- 
tion program, said request for digital token including 
predetermined information required by said token 
generation means, said communications module 
sends said request for digital token and said prede- 
termined information to said portable vault means 

_and receives from said portable vault means a 
transaction record including a digital token gener- 
ated by said token generation mans, said indicia 
image creation and storage module generates an 
indicia bitmap from said digital token and stores 
said indicia bit map, said transaction capture mod- 
ule stores said transaction record said application 
interface module provides said indicia bitmap to 
said non-metering application program. 

16. The transaction evidencing system of claim 15 
wherein said communications module maintains 
communication data integrity with said portable 
vault means through the use of a session key for 
each transaction evidencing communication ses- 
sion relating to a request for and receipt of a digital 
token. 

17. The transaction evidencing system of daim 16 
wherein said communications module also controls 
secure communications with a postal data center 
during refills of accounting registers in said transac- 
tion accounting means of said portable vault 
means. 
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18. The transaction evidencing system of claim 17 
wherein said portable vault means comprises a plu- 
rality of portable vault devices, any one of which 
may be coupled to said PC for each transaction evi- 
dencing communication session, and wherein said 
transaction capture module monitors communica- 
tions between each of said vault devices and said 
communications module and stores in said storage 
means all transaction records and refill accounting 
information received by said communications mod- 
ule for each of said vault devices, whereby said 
storage means is a backup of information stored in 
said vault devices. 

19. A method of implementing a transaction evidencing 
system on a personal computer (PC) having a dis- 
play and an unsecured printer operatively coupled 
thereto, comprising the steps of: 

providing a portable vault that is removably 
coupled to the personal computer, said porta- 
ble vault operating as a secure accounting 
module of the transaction evidencing system; 
requesting indicia for a particular document 
being processed in an application program run- 
ning in the PC; 

securely sending from an application interfac- 
ing module in the PC, in response to said 
request for indicia, a request for at least one 
digital token to said vault with a predetermined 
set of information relating to the particular doc- 
ument; 

issuing in said vault at least one digital token 
and securely sending the digital token to an 
indicia generating module in the PC; 
storing the digital token and the predetermined 
set of information in a transaction record; 
generating an indicia bitmap using the transac- 
tion record; and 

providing the indicia bitmap to the application 
program when the application program is ready 
to print the indicia. 

20. The method of claim 1 9, comprising the further step 
of: 

viewing on a PC display an image of at least a 
part of the particular document with the indicia 
shown thereon before printing the particular 
document. 

21 . The method of claim 1 9, comprising the further step 
of: 



22. The method of claim 19 t comprising the further 
steps of: 

providing a dynamic link library (DLL) contain- 
5 ing routines for controlling communications 

with the portable vault, storing transactions, 
storing indicia bitmaps, and application inter- 
facing; 

loading the DLL into the memory of the PC 
10 when an indicia request is made from the appli- 

cation program; and 

accessing the DLL from the application pro- 
gram. 

15 23. The method of claim 19, comprising the further 
steps of: 

selecting in the application program recipient 
address information for in the application pro- 
20 gram; 

selecting in the application program an amount 
of postage to be printed on in the application 
program; 

including the recipient address information and 
25 the amount of postage as part of the predeter- 

mined set of information; and 
printing said recipient address and said indicia 
on an envelope. 

30 24. The method of claim 19, comprising the further 
steps of: 

printing the indicia directly on the document; 
and 

inserting the document into an envelope such 
that the indicia is visible through a windowed 
portion of the envelope. 

25. A transaction evidencing system including a plural- 
40 ity of computer systems operatively configured to 
form a network with one of the computer systems 
functioning as a server and the remaining computer 
systems functioning as clients, each of the compu- 
ter systems including processor, memory, storage 
45 and user interface means, at least some of said 
storage means including a plurality of non-metering 
application programs that are selectively run on 
said client computer systems, at lease one of said 
computer systems including an unsecured printer 
so operatively coupled thereto for printing in accord- 
ance with said non-metering application programs, 
the system comprising: 

a portable vault card that is removable coupled 
to said server computer system, said vault card 
including digital token generation means and 
transaction accounting means, said server 
computer system including means for remova- 
ble coupling said vault card to said PC; 



storing a plurality of transaction records on the 55 
hard drive, each of the transaction records cor- 
responding to transactions occurring in said 
portable vault: 
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vault interface means for effecting communica- 
tions between said portable vault means and 
said non-metering application program and for 
performing metering functions other than 
metering functions performed in said portable 
vault means, said vault interface means com- 
prising: 

an application interface module in said client 
computer system for interfacing with said non- 
metering application program; 
a communications module in said server com- 
puter system for communicating with said port- 
able vault means; 

an indicia image creation and storage module 
in said client computer system for generating 
indicia bitmaps and storing said indicia bitmaps 
in said storage means; and 
a transaction capture module for storing stor- 
age means transaction records generated in 
said portable vault means. 



28. The transaction evidencing system of claim 25, 
wherein a batch of digital tokens may be generated 
in the vault card and stored in a requesting one of 
said client computer systems before any indicia bit- 
maps corresponding to said batch of digital tokens 
are generated. 



31 



The transaction evidencing system of claim 25, 
wherein said vault interface means provides said 
indicia bitmap to said one of said non-metering 
application programs for viewing an image of said 
indicia bitmap on a display coupled to said request- 
ing client computer system before printing said indi- 
cia bitmap. 



32. The transaction evidencing system of claim 25 
wherein said indicia bitmap generating means gen- 
erates a postage indicia bitmap by combining indi- 
cia graphics stored in said storage means of said 
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26. The transaction evidencing system of claim 25, 
wherein said vault interface means are part of 
dynamic link library modules in said computer sys- 
tems. 25 

27. The transaction evidencing system of claim 25, 
wherein said vault card is a PCMCIA card. 



30 



35 



29. The transaction evidencing system of claim 25, 
wherein said transaction record is encrypted before 
being stored in said storage means of said server 
computer system. 40 



30. The transaction evidencing system of claim 25, 
wherein a plurality of consecutive ones of said 
transaction records are stored in said storage 
means of said server computer system as backup 
to information stored in said vault card. 



45 



50 



55 



requesting client computer system with said digital 
token and said predetermined information. 

33. The transaction evidencing system of daim 25 
wherein said application interface module issues a 
request for at least one digital token in response to 
a request for indicia from said non-metering appli- 
cation program.said request for digital token includ- 
ing predetermined information required by said 
token generation means, said communications 
module sends said request for digital token and 
said predetermined information to said portable 
vault means and receives from said portable vault 
means a transaction record including a digital token 
generated by said token generation means, said 
indicia image creation and storage module gener- 
ates an indicia bitmap from said digital token and 
stores said indicia bit map, said transaction capture 
module stores said transaction record said applica- 
tion interface module provides said indicia bitmap 
to said non-metering application program. 

34. The transaction evidencing system of claim 33 
wherein said transaction capture module in said 
server and client computer systems. 

35. The transaction evidencing system of claim 25 
wherein said transaction capture module in said 
server computer system. 

36. A method of implementing a transaction evidencing 
system on a computer network comprising a plural- 
ity of computer systems operatively configured to 
form the computer network with one of the compu- 
ter systems functioning as a server and the remain- 
ing computer systems functioning as clients, the 
method comprising the steps of: 

providing a portable vault that is operatively 
coupled to the the server, said vault operating 
as a secure accounting module of the transac- 
tion evidencing system; 
requesting indicia in one of the clients for a par- 
ticular document being processed in a non- 
metering application program running in the 
requesting client; 

sending the request for indicia from the 
requesting client to the server with a predeter- 
mined set of information relating to the particu- 
lar document; 

sending, in response to said request for indicia, 
a request for at least one digital token from the 
server to the portable vault with the predeter- 
mined set of information; 
issuing in said portable vault at least one digital 
token and sending the digital token as part of a 
transaction record to the server; 
storing the transaction record in the server; 
sending from the server to the requesting client 
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the digital token and a predetermined set of " 
information of the transaction record; 
storing transaction record in the client; 
generating an indicia bitmap using the digital 
token and the predetermined set of information 5 
in the client; and 

providing the indicia bitmap to the non-meter- 
ing application program when the non-metering 
application program is ready to print the indicia. 

10 

37. The method of claim 36, comprising the further step 
of: 

viewing on a display coupled to the requesting 
client computer system an image of at least a 15 
part of the particular document with the indicia 
shown thereon before printing the particular 
document. 

38. The method of claim 36, comprising the further step 20 
of: 

storing a plurality of transaction records in a file 
on a hard drive of the server, and indexing the 
tranaction records according to piece count. 25 

39. The method of claim 36, comprising the further 
steps of: 

selecting in the non-metering application pro- 30 
gram recipient address information for use in 
the application program; 
selecting in the non-metering application pro- 
gram an amount of postage to be printed on in 
the application program; _ . 35 

including the recipient address information and 
the amount of postage as part of the predeter- 
mined set of information; and 
printing said recipient address and said indicia 
on an envelope. 40 
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